MacTech 1 to 12/MacTech-vol-1-12.toast/Reference/the cmsp digests ('94-'97)/csmp digest Vol 3 No 091

Text File | 1995-03-31 | 57KB | 1,589 lines

C.S.M.P. Digest             Fri, 31 Mar 95       Volume 3 : Issue 91

Today's Topics:

        Communications Toolbox
        Displaying INIT icons (followup)
        Help with Macintosh Serial Driver
        How to write-read files
        Large Resource Files
        Making an Edit Text Inactive
        Need help learning Handles -- Pascal
        OSAExecute and AS subroutines
        [Ann] FREE QuickView Development Kit
        [HELP] How would I add to the Help Menu?



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                                Sends you a summary of commands
    subscribe csmp-digest Your Name     Adds you to the mailing list
    signoff csmp-digest                 Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail].

-------------------------------------------------------

>From [e-mail] (Michael Bayme)
Subject: Communications Toolbox
Date: Tue, 07 Mar 1995 13:11:35 -0500
Organization: Beth Israel Hospital Boston Department of Surgery

What's the deal with the Comm Toolbox? Is it going to remain part of the
system? How come there's no sample programs on the apple server - they
used to have something called 'surfer'? Is there a NIM-Comm Toolbox?
Thanks.

Beth Israel Hospital Boston, Department of Surgery
[phone]

+++++++++++++++++++++++++++

>From [e-mail] (Eric Scouten)
Date: Wed, 08 Mar 1995 16:57:55 -0600
Organization: metrowerks, inc.

In article <[e-mail]>,
[e-mail] (Michael Bayme) wrote:

> What's the deal with the Comm Toolbox? Is it going to remain part of the
> system? How come there's no sample programs on the apple server - they
> used to have something called 'surfer'? Is there a NIM-Comm Toolbox?
> Thanks.

CTB will remain part of the system software and will be enhanced (as part
of Copland) to work with/take advantage of Open Transport in a logical
manner.

There is no NIM-Comm Toolbox, but the CTB is documented in a volume titled
"Inside the Macintosh Communications Toolbox." I don't have it handy, else
I'd give you the ISBN.

Dunno what became of Surfer.

-es

__________________________________________________________________________
Eric Scouten                                       Constructor Constructor
[e-mail]                                     Metrowerks, Inc.

               OUT OF TOWN March 4-7: limited net access

They [Murphy's] must optimize their grease for onion rings.
   -Jon Roma

+++++++++++++++++++++++++++

>From [e-mail] (KID SNOOPY)
Date: 14 Mar 1995 17:46:55 -0500
Organization: America Online, Inc. (1-800-827-6364)

Just picked up a copy the ISBN is 0-201-57775-5

It has lots of good sample code!

Tom Harkins

---------------------------

>From [e-mail] (Francois Pottier)
Subject: Displaying INIT icons (followup)
Date: 11 Mar 1995 15:46:03 GMT
Organization: Ecole Normale Superieure, PARIS, France

Hello,

Oops! I found a severe bug in the code I posted yesterday. I should
have allocated four more bytes of storage at the end of the QuickDraw
globals; QuickDraw wants to store a pointer to its globals there.

Amusingly, this is only a problem on 68K Macs; on PowerMacs it works just
fine, probably because the way A5 worlds work is different on PowerMacs. This
explains why I didn't find the bug at first.

Happy patching

--
Francois
[e-mail]
http://acacia.ens.fr:8080/home/pottier/index.html

--
Francois Pottier                                            [e-mail]
- ----------------------------------------------------------------------------
Check my WWW page at http://acacia.ens.fr:8080/home/pottier/index.html ...

---------------------------

>From [e-mail] (Chad A. Ryan)
Subject: Help with Macintosh Serial Driver
Date: Wed, 15 Mar 95 23:22:42 GMT
Organization: Case Western Reserve University


I am currently developing an interface between a Casio digital diary and
a Macintosh.  I am using the Serial Driver to transfer the data through the
serial modem port.  I have no problem opening or closing the port, writing
to the port, or changing the default settings for the port but when I try to
read from the port I have problems.

To big problem is that I can only read 63 bytes.  I call the "SerGetBuf"
function to get the number of bytes in the buffer.  If it is less than 63
bytes it returns the correct value but anything more than that and it returns
63.  I have also tried getting the number of bytes in the input buffer
by calling the "PBStatus" and "Status" functions and they also only
return 63 bytes.

I am certain that it is not the Casio that has the problem because even
if I connect the transmit pin directly to the receive I have the same problem
but with an interesting twist:  It actually reads the entire string that I sent
even if it is longer than 63 bytes but it tells me that it only read 63.

If anyone has any clue what I could be doing wrong I would appreciate any
help you can offer.

Thanks in advance -

Chad Ryan
[e-mail]
[e-mail]


+++++++++++++++++++++++++++

>From David Shortt <[e-mail]>
Date: 16 Mar 1995 06:31:28 GMT
Organization: RAIN Public Access Internet (805) 967-RAIN

[e-mail] (Chad A. Ryan) wrote:
>
>
> I am currently developing an interface between a Casio digital diary and
> a Macintosh.  I am using the Serial Driver to transfer the data through the
> serial modem port.  I have no problem opening or closing the port, writing
> to the port, or changing the default settings for the port but when I try to
> read from the port I have problems.
>
> To big problem is that I can only read 63 bytes.  I call the "SerGetBuf"
> function to get the number of bytes in the buffer.  If it is less than 63
> bytes it returns the correct value but anything more than that and it returns
> 63.  I have also tried getting the number of bytes in the input buffer
> by calling the "PBStatus" and "Status" functions and they also only
> return 63 bytes.
>
> I am certain that it is not the Casio that has the problem because even
> if I connect the transmit pin directly to the receive I have the same problem
> but with an interesting twist:  It actually reads the entire string that I sent
> even if it is longer than 63 bytes but it tells me that it only read 63.
>
> If anyone has any clue what I could be doing wrong I would appreciate any
> help you can offer.
>
> Thanks in advance -
>
> Chad Ryan
> [e-mail]
> [e-mail]
>

>From Inside Mac, volume II, p. 246:  "Each input driver's buffer can
initially hold up to 64 characters, but your application can specify
a larger buffer if necessary."

You may be using the default buffer of 64 characters and not reading
fast enough to prevent a software overflow.  If this is the case,
you should see the "cumErrs" byte of a SerStaRec record contain the
value 1 after a call to SerStatus.  The fix is to set a longer buffer
before reading, something like this:

type
  myBufType = packed array[1..1024] of char; {or however big you need}
  pMyBufType = ^myBufType;
var
  myBuf: pMyBufType;
begin
  myBuf:= pMyBufType(NewPtr(SizeOf(myBufType)));

  ...  {open serial drivers, get refNum of port, etc.}

  SerSetBuf(refNum, @myBuf[1], 1024);

  ...  {use port normally at this point}
end;

I hope this helps.

Dave Shortt
[e-mail]




+++++++++++++++++++++++++++

>From [e-mail] (Chris Wysocki)
Date: Fri, 17 Mar 1995 01:29:59 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

In article <3k7t0o$[e-mail]>,
Chad A. Ryan <[e-mail]> wrote:

>To big problem is that I can only read 63 bytes.  I call the "SerGetBuf"
>function to get the number of bytes in the buffer.  If it is less than 63
>bytes it returns the correct value but anything more than that and it returns
>63.  I have also tried getting the number of bytes in the input buffer
>by calling the "PBStatus" and "Status" functions and they also only
>return 63 bytes.

The default size of the serial input buffer is 64 bytes.  If you want
a larger buffer, you need to allocate it yourself and tell the serial
driver to use it via a SerSetBuf Control call (csCode 9).

Chris.

---------------------------

>From [e-mail] (Alan Long)
Subject: How to write-read files
Date: 10 Mar 1995 06:27:09 MST
Organization: Motorola

     I'm trying to get to grips with how to write to and read from files,
using Think C 6.0.  I've got a Struct in my program, containing Str255,
char and int variables.  I'd simply like to write this Struct to a file,
and read it back into the Struct.

     Can someone point me in the right direction?  Do I need to convert
the Struct to a TextEdit record and then write/read?  I don't want to
look up this path if it then turns out to be completely the wrong
strategy.

     A few clues would greatly help me to research the details.

Regards,
Alan

+++++++++++++++++++++++++++

>From [e-mail] (Sean Crist)
Date: 10 Mar 1995 17:09:27 GMT
Organization: University of Pennsylvania, Linguistics Department

In article <[e-mail]>,
Alan Long <[e-mail]> wrote:
>     I'm trying to get to grips with how to write to and read from files,
>using Think C 6.0.  I've got a Struct in my program, containing Str255,
>char and int variables.  I'd simply like to write this Struct to a file,
>and read it back into the Struct.
>
>     Can someone point me in the right direction?  Do I need to convert
>the Struct to a TextEdit record and then write/read?  I don't want to
>look up this path if it then turns out to be completely the wrong
>strategy.
>
>     A few clues would greatly help me to research the details.

Basically, you've got two choices: you can either use the data fork or the
resource fork.  There's difference of opinion on this, but I personally use
the resource fork to store everything; the resource manager is very
convenient to use, and its performance only starts to degrade when you're
handling relatively large amounts of data, or when you're doing something
like a spreadsheet or large-scale database where the format of the file
starts making a crucial difference in time performance.  But if you just
want to store and retrieve a single structure containing a few variables, I
would definitely use the resource manager to do it.

I don't know C, but in rough terms, here's what you would do:

-Create a handle to your structure with NewHandle, doing the necessary
 typecasting (maybe C doesn't require the typecasting; I don't know.)
-Create and open your resource file, if necessary
-Use AddResource to add your handle as a resource to the file,
 using some custom resource type not used by the system.

Read up on the resource manager: once you understand what it's doing, it's
very easy to use.

  \/ __ __    _\_     --Sean Crist  ([e-mail])
 ---  |  |    \ /     For a free copy of the Bill of Rights, finger
  _| ,| ,|   -----       this account.
  _| ,| ,|    [_]     Q: What do Standard Oil, AT&T, and Microsoft have in
   |  |  |    [_]        common?   A:  Nothing... yet.






+++++++++++++++++++++++++++

>From [e-mail] (James Deline)
Date: Sun, 12 Mar 1995 05:18:47 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

Alan,

Learn how to use the standard library routines, it makes life a whole lot
simpler.  Here's how:

#include <stdio.h>

FILE    *myfile;
int     result;
size_t  numwritten;
struct mystruct {
Str255  s;
char    c;
int     i;
} mystruct;

myfile = fopen ("filename", "w");       // open file for writing
// error check here
numwritten = fwrite (&mystruct, sizeof(mystruct), 1, myfile); // write one
result = fclose (myfile);       // close the file

//////////////////

It's just that easy, with the caveat that the file will be created in the
same directory as your program, and when you use fread to read it, it
must also be in the same directory.  If it's not, you will have to get a
little more fancy.

--
//////////////////////////////////////////
James Deline, Ph.D.
Chemist and part-time software writer
My opinions are not necessarily my own
//////////////////////////////////////////


+++++++++++++++++++++++++++

>From [e-mail] (Peter N Lewis)
Date: Thu, 16 Mar 1995 13:45:56 +0800
Organization: Curtin University

In article <3jq147$[e-mail]>, [e-mail]
(Sean Crist) wrote:

>-Create a handle to your structure with NewHandle, doing the necessary
> typecasting (maybe C doesn't require the typecasting; I don't know.)

Actually, use PtrToHand, which takes a ptr to your struct, and the size of
the struct and returns you a brand new handle.

PtrToHand, PtrToXHand, HandAndHand, HandToHand, and of course Munger are
underused by most programmers.  Take a few minutes to read up on these
routines (well, a few hours for Munger, my absolute favouritist call :-)

>-Create and open your resource file, if necessary
>-Use AddResource to add your handle as a resource to the file,
> using some custom resource type not used by the system.
>
>Read up on the resource manager: once you understand what it's doing, it's
>very easy to use.

I'm not sure I can agree with that statement.  The Resource Manager is
filled with gotchas.  Practically every operation is has problems with
it.  Adding a resource is one, since AddResource does not overwrite an
existing resource with the same ID, so replacing a resource it a
nightmare.

Here's some code to write a resource:

      SetResLoad(false);
      resfile := FSpOpenResFile(res.fs, fsRdWrPerm);
      err := ResError;
      SetResLoad(true);
      if err = noErr then begin
         h := Get1Resource(res.typ, res.id);
         if h <> nil then begin
            RmveResource(h);
         end;
         AddResource(res.data, res.typ, res.id, res.name);
         err := ResError;
         if err = noErr then begin
            WriteResource(res.data);
            SetResAttrs(res.data, res.attributes);
            err := ResError;
            DetachResource(res.data);
         end;
         CloseResFile(resfile);
      end;

Note the gotchas in this code:

SetResLoad(false) stops the Resource Manager from filling your heap with
any resources marked preload (I failed to remember this one just
recently).  Be careful to quickly set it back to true - if you cause a
segment load while SetResLoad is false, you'll crash and burn.

Then it gets and removes the resource if it exists already (an alternative
is to get the resource, change the data and then write it back).

Then it adds the resource.  If this succeeds, then the handle is now a
resource handle, if it fails, the handle is still a memory handly. Be very
careful, you must resolve this dichotomy otherwise you'll never be able to
correctly dispose of the handle (DisposeHandle/ReleaseResource).

Write the resource

Set the resource attributes if necessary.

Detach the resource to ensure we know that the handle is a memory handle
again, so we can finish with handle by calling DisposeHandle.  Another
option is to set res.data to nil and let the CloseResFile ReleaseResource
the handle for you, and then DisposeHandle(res.data) (DisposeHandle is
nil-safe.  DisposePtr is not).

Close the resfile (which would have ReleaseResourced the handle if we
hadn't detached it).

Enjoy,
   Peter.
--
The best movie I've seen recently is "Heavenly Creatures" from New Zealand

---------------------------

>From [e-mail] (Glenn M. Berntson)
Subject: Large Resource Files
Date: Mon, 13 Mar 1995 09:31:56 -0400
Organization: Harvard University

I have an application whose RAM partition size I'd like to keep as small
as possible.  However, one of the things this application does is allow
the user to modify SIZE resources of other applications (thanks to
suggestion of Manfred Wuttke).

The problem I face is that in order to get at the SIZE resources, I have
to open the application's resource fork.  I am currently using
FSpOpenResFile.  If I don't allocate a large enought RAM partition to my
own application, opening a large applications resource fork gives me a
system error #25.

As I see it, I have two options:

1 - figure out a way to load A SINGLE resource from a resource fork
without opening the entire file.

2 - determine the size of the resource fork prior to calling
FSpOpenResFile to see if an error # 25 would occur and not open the file
if it would.

At this stage I can't figure out how to do either of these operations.

Any suggestions would be really helpful.

Thanks!!

Glenn

+++++++++++++++++++++++++++

>From [e-mail] (Reinder Verlinde)
Date: Mon, 13 Mar 1995 17:12:00 GMT
Organization: Rijksuniversiteit Utrecht

In article <[e-mail]>,
[e-mail] (Glenn M. Berntson) wrote:

>
> 1 - figure out a way to load A SINGLE resource from a resource fork
> without opening the entire file.
>
First, do a SetResLoad( false). Then call FSpOpenResFile. This prevents
the OpenResFile from loading in resources with the 'preloaded' bit set.
This is what causes the out of memory error.
After this, do SetResLoad( true), and call Get1Resource( 'SIZE', ...),
or whatever you do (Count1Resources, ...)
The SetResload and FSpOpenResFiles should be as close together as possible,
to prevent nasty surprises.

Reinder Verlinde

+++++++++++++++++++++++++++

>From [e-mail] (Marshall Clow)
Date: 16 Mar 1995 06:45:29 GMT
Organization: Aladdin Systems

In article <[e-mail]>,
[e-mail] (Glenn M. Berntson) wrote:

> I have an application whose RAM partition size I'd like to keep as small
> as possible.  However, one of the things this application does is allow
> the user to modify SIZE resources of other applications (thanks to
> suggestion of Manfred Wuttke).
>
> The problem I face is that in order to get at the SIZE resources, I have
> to open the application's resource fork.  I am currently using
> FSpOpenResFile.  If I don't allocate a large enought RAM partition to my
> own application, opening a large applications resource fork gives me a
> system error #25.
>
[ snip ]
> Any suggestions would be really helpful.
>

I see two problems that you may be having:

1) When you open a resource file, all the resources marked as 'preload'
get loaded. This is easy to fix. Call ResLoad(false) before the open, and
ResLoad(true) after. No resources will be loaded.

2) The other problem is a bit more involved, but is quite likely what is
going on. Suppose you open a resource file, then call a routine in another
segment (that is not currently loaded) What happens? Well, _LoadSeg does a
GetResource ( 'CODE, n), which loads a resource FROM THE FILE THAT YOU
JUST OPENED, and jumps to the correct offset in that resource for the
routine in your application. Boom.
    The way to solve this is to mange the resource map chain yourself.
After you have opened the file, do a UseResFile back to your application.
When you want to load a resource from the file you are working on you do:

   short saveResFile;

   saveResFile = CurResFile ();
   UseResFile ( rsrcForkRefNum );
   h = Get1Resource ( ... );
   UseResFile ( saveResFile );

This will load a resource from the file with refNum "rsrcForkRefNum".

[ Except of course, if the file is the system file, or a font file, or
ROM, or, or, or... Thanks a lot, Dean. ]

-- Marshall

--
Marshall Clow
Aladdin Systems
[e-mail]

---------------------------

>From [e-mail] (Doug Williams)
Subject: Making an Edit Text Inactive
Date: 13 Mar 1995 03:59:17 GMT
Organization: University of Arizona, Tucson, AZ

Is there a clean way to make an Edit Text item in a modal dialog
inactive?  HiliteControl doesn't work, because it really doesn't have
access to a true control.  I pulled something called DialogBits off an
Apple server a while ago, and it's method was as follows: set up a
user item which covers the Edit Text.  If the field should be
inactive, it will paint the rect in notPatBic mode.  Then in the
filter proc, it fakes the Dialog Manager into ignoring clicks in the
Edit Text.  I have two problems with this method: 1) I can see the
text get drawn first regularly, then get greyed out (possibly because
I have a user item with an involved drawing scheme inbetween the Edit
Text and its associated User Item). 2) This scheme makes the greyed
out text look dithered, instead of using a nice grey.

So, is there a cleaner way of making an Edit Text Item in a modal
dialog inactive??

-=-doug-=-



+++++++++++++++++++++++++++

>From [e-mail] (MHGrueter)
Date: 15 Mar 1995 12:50:29 -0500
Organization: America Online, Inc. (1-800-827-6364)

>> Is there a clean way to make an Edit Text item in a modal dialog
inactive?

Doug,

I was just looking for something similar yesterday, and I found some code
called "DimText 2.0" on the Apprentice (release 2) CD ROM.  It looks like
what you want.  You can also get it via FTP.  Here is the blurb that came
up in the CD index:


DimText 2.0
James Walker
[e-mail]
Apprentice:Source Code:C:Libraries:
ftp://ftpbio.bgsu.edu/alt.sources.mac/vol-06/
__________
DimText allows you to dim statText and editText items in a dialog without
any extra dialog items, etc. A demo application is included. To use the
"Dim_text()" function, your dialog can't be using the refCon field or
QuickDraw bottleneck. (Not a big deal, IMHO).  Real "gray" is used if it's
available.


- Mike

+++++++++++++++++++++++++++

>From [e-mail] (MHGrueter)
Date: 15 Mar 1995 12:50:29 -0500
Organization: America Online, Inc. (1-800-827-6364)

>> Is there a clean way to make an Edit Text item in a modal dialog
inactive?

Doug,

I was just looking for something similar yesterday, and I found some code
called "DimText 2.0" on the Apprentice (release 2) CD ROM.  It looks like
what you want.  You can also get it via FTP.  Here is the blurb that came
up in the CD index:


DimText 2.0
James Walker
[e-mail]
Apprentice:Source Code:C:Libraries:
ftp://ftpbio.bgsu.edu/alt.sources.mac/vol-06/
__________
DimText allows you to dim statText and editText items in a dialog without
any extra dialog items, etc. A demo application is included. To use the
"Dim_text()" function, your dialog can't be using the refCon field or
QuickDraw bottleneck. (Not a big deal, IMHO).  Real "gray" is used if it's
available.


- Mike

---------------------------

>From [e-mail] (Rhys EleScryer)
Subject: Need help learning Handles -- Pascal
Date: Wed, 08 Mar 1995 09:11:12 -0500
Organization: The Jourvian Group

I am currently trying for the first time in any of my programs to use a handle.
I just don't quite have the hang of it. Here's what I've done:
After putting some text into a string variable (theString):

theHandle:= NewHandle(SizeOf(theString));
theHandle^:= @theString;

This is just plain wrong. I mean it compiles and runs fine, but I end up
with garbage in my variable. Could some kind soul point me in the right
direction when it comes to these nasty buggers?
TIA!
Jaeson

--
                                    (EMAIL responces preferred)
http://cybercronx.techwood.org  |  [e-mail]
                               Finger me for my public PGP block.
                     Host of the DaemaCron Cybernet Hub +089427;

+++++++++++++++++++++++++++

>From [e-mail] (Sean Crist)
Date: 9 Mar 1995 18:23:36 GMT
Organization: University of Pennsylvania, Linguistics Department

In article <[e-mail]>,
Rhys EleScryer <[e-mail]> wrote:
>I am currently trying for the first time in any of my programs to use a
>handle.
>I just don't quite have the hang of it. Here's what I've done:
>After putting some text into a string variable (theString):
>
>theHandle:= NewHandle(SizeOf(theString));
>theHandle^:= @theString;
>
>This is just plain wrong. I mean it compiles and runs fine, but I end up
>with garbage in my variable. Could some kind soul point me in the right
>direction when it comes to these nasty buggers?
>TIA!

The line "theHandle^:= @theString;" is a major no-no.  "@theString" is a
pointer to where your string is stored on the stack.  "TheHandle^" is a
pointer to the memory manager's master pointer to the memory block you
allocated with the call to NewHandle (read that sentence 3 times or so; it
makes more sense if you remember that a handle is a pointer to a pointer).
The memory block referred to by TheHandle^^ is in the heap, not the stack.

What you're doing in the no-no line is screwing up the memory manager; as a
result of that line, the memory manager thinks there's a relocatable memory
block in the middle of your stack.  If the memory manager needs to move
things around, it's going to yank stuff right out of your stack and move it
someplace else, which could cause any kind of crash.

What is it that you're trying to do?  If you want to _copy_ the contents of
the stack variable 'theString' into the memory block referred to by
TheHandle^^, here's how I'd do it:

type
  StringPtr = ^Str255;
  StringHandle = ^StringPtr;
var
  TheStringHandle : StringHandle;
  OkSoFar : Boolean;
begin
  OkSoFar := TRUE;
  TheStringHandle := StringHandle(NewHandle(SizeOf(Str255)));
  if MemErr <> 0 then
    OkSoFar := FALSE;

  if OkSoFar then
    TheStringHandle^^ := TheString;

etc.

This, of course, is more verbose than it needs to be, but I'm doing this to
point out several things:
1) I'm using typecasting to trick Pascal into thinking this regular handle
   is a handle to a Str255.  The memory manager could care less what you
   write into the memory block, but Pascal will give you a type mismatch
   if you try to say MyRegularHandle^^ := TheString.  (Actually, I think
   Macintosh Pascal may already have a handle to a Str255 defined, but I
   just defined it again.)
2) You _must_ check MemErr to make sure the memory allocation was
   successful.  You will be really sorry if you don't ("A system that's
   designed without failure in mind is sure to"- the original version of
   Murphy's Law).  In this case, if the allocation fails, and you try
   writing to the handle anyway, you'll be writing to some random place
   in memory, causing any kind of crash (perhaps not immediately).
         Everyone has their own way of dealing with the failure;
   my way, as I've demonstrated, is to set an OkSoFar boolean to TRUE at
   the beginning of the routine, and to set it to FALSE as soon as there is
   a fatal failure somewhere.  I bracket all my code into meaningful
   paragraphs which start with 'if OkSoFar then begin...'; if there's been
   a failure, I'll just fall through to the end of the routine.  Of course,
   you'll want to have some kind of error reporting, but I haven't
   demonstrated this here; write to me if you want some suggestions on
   how to do this efficiently.  Also, sometimes there will be extra things
   you need to do to handle a failure, but the technique I've used here
   covers a lot of the ordinary cases.

Hope this helps.

  \/ __ __    _\_     --Sean Crist  ([e-mail])
 ---  |  |    \ /     For a free copy of the Bill of Rights, finger
  _| ,| ,|   -----       this account.
  _| ,| ,|    [_]     Q: What do Standard Oil, AT&T, and Microsoft have in
   |  |  |    [_]        common?   A:  Nothing... yet.

+++++++++++++++++++++++++++

>From [e-mail] (Eric Jackson)
Date: Fri, 10 Mar 1995 18:00:03 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

In article <[e-mail]>,
Rhys EleScryer <[e-mail]> wrote:
>I am currently trying for the first time in any of my programs to use a
>handle.
>I just don't quite have the hang of it. Here's what I've done:
>After putting some text into a string variable (theString):
>
>theHandle:= NewHandle(SizeOf(theString));
>theHandle^:= @theString;
>
>This is just plain wrong. I mean it compiles and runs fine, but I end up
>with garbage in my variable. Could some kind soul point me in the right
>direction when it comes to these nasty buggers?
>TIA!
Another way to get a string handle is with this function

Function NewString(theString:str255):StringHandle;
You will find it under tool box utilities on page 468
of the old inside machintosh volume one and I think it must
also be somewhere in the new versions as well.

Eric Jackson
[e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Ingemar Ragnemalm)
Date: 12 Mar 1995 09:36:52 GMT
Organization: (none)

[e-mail] (Sean Crist) writes:

>In article <[e-mail]>,
>Rhys EleScryer <[e-mail]> wrote:
>>I am currently trying for the first time in any of my programs to use a
>>handle.
>>I just don't quite have the hang of it. Here's what I've done:
>>After putting some text into a string variable (theString):
>>
>>theHandle:= NewHandle(SizeOf(theString));
>>theHandle^:= @theString;
>>
>>This is just plain wrong. I mean it compiles and runs fine, but I end up
>>with garbage in my variable. Could some kind soul point me in the right
>>direction when it comes to these nasty buggers?
>>TIA!

Yes, it's just plain wrong. If you want to copy the string into the
handle, I would try

if theHandle <> nil then
  StringHandle(theHandle)^^ := theString;

>type
>  StringPtr = ^Str255;
>  StringHandle = ^StringPtr;

Note that those types are predeclared in "general-purpose data types" so you
don't have to.

--
- -
Ingemar Ragnemalm, PhD
Image processing, Mac shareware games
E-mail address: [e-mail] or [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Esa Ristil{)
Date: 10 Mar 1995 16:10:43 +0200
Organization: University of Tampere, Finland

According to Rhys EleScryer:
>theHandle:= NewHandle(SizeOf(theString));
>theHandle^:= @theString;

Handles needs to be dereferenced twice, that is
theHandle^^ := @theString

If there is only one ^ you will be pointing to the handle's
masterpointer and that is a no no.

--
         Esa Ristild         *         http://www.uta.fi/~eesau/
         [e-mail]        *         Homo homini lupus

+++++++++++++++++++++++++++

>From David Shortt <[e-mail]>
Date: 13 Mar 1995 09:00:30 GMT
Organization: RAIN Public Access Internet (805) 967-RAIN

[e-mail] (Rhys EleScryer) wrote:
>
> I am currently trying for the first time in any of my programs to use a handle.
> I just don't quite have the hang of it. Here's what I've done:
> After putting some text into a string variable (theString):
>
> theHandle:= NewHandle(SizeOf(theString));
> theHandle^:= @theString;
>
> This is just plain wrong. I mean it compiles and runs fine, but I end up
> with garbage in my variable. Could some kind soul point me in the right
> direction when it comes to these nasty buggers?
> TIA!
> Jaeson

The first thing to remember about a handle is that it is a pointer to a
pointer.  If you had a string pointer called myStrPointer, you could fill
it like this:

  var
    theString: Str255;
    myStrPointer: StringPtr;

  begin
    theString:= 'abcdefghijklmnopqrstuvwxyz';  {any text}
    myStrPointer:= StringPtr(NewPtr(SizeOf(Str255)));
    myStrPointer^:= theString;

This works because myStrPointer is a pointer to a str255, so
myStrPointer^ is a str255; therefore myStrPointer^ can be set equal to
another string.  Note: always allocate enough space for the biggest
possible string, just to be safe.  You could also write

  myStrPointer:= @theString;

In this case you're setting two pointers equal.

Now let's do a handle.  I would write it like this:

  var
    theString: Str255;
    myStrHandle: StringHandle;

  begin
    theString:= 'abcdefghijklmnopqrstuvwxyz';  {any text}
    myStrHandle:= StringHandle(NewHandle(SizeOf(Str255)));
    myStrHandle^^:= theString;

The final line works because you first de-reference the handle once to
create a pointer, then de-reference a second time to make the string
itself.  You can then assign this to any string.  In this case you CANNOT
do something like this:

    myStrHandle:= @@theString;  {don't do this!}

because you can't just make a handle out of a variable.  Also, don't
forget to dispose of the handle you created when you're done, like this:

    DisposeHandle(Handle(myStrHandle));  {sometimes named DisposHandle}
    myStrHandle:= nil;

I always set a handle (or a pointer) back to nil when I dispose of it.
That way if I accidentally access it again (illegally), it generates a
more predictable error.

If you've never used handles before, you may wonder why bother.  The
reason is that when you create a handle, the operating system keeps track
of the handle, _and_ an internal pointer which actually points to the
data.  Now let's suppose you allocate a lot of handles for long arrays of
numbers, for storing a picture or something.  If you allocate and
deallocate different length arrays in different orders, your memory can
become fragmented.  If they're all pointers, there is nothing the
operating system can do, except fail at some point :(.  But if they're
handles, the operating system can move memory around and change the value
of the "master pointer" for each handle.  In our example, the value of
myStrHandle never changes, but the operating system can change the value
of myStrHandle^ if it wants to, as long as it moves the data around to
match.  This way, the OS can compact memory as long as everything is
handles.  This happens, if necessary, whenever you call NewHandle.
Pretty neat!  I was fascinated when I found this out, and remember, the
Mac has been doing this since 1984!

Sometimes you need to have a pointer, not a handle.  This can happen if
you want to pass a pointer to some data to an operating system routine.
In this case it is wise to "lock" the handle before passing it's
de-referenced pointer:

    HLock(myStrHandle);
    myStrPtr:= myStrHandle^;  {de-reference once to get master pointer}
    ProcedureWhichTakesAPointer(myStrPtr);
    HUnlock(myStrHandle);

Locking the handle tells the operating system not to move that handle's
memory around.  If it moved memory around after you were playing with the
pointer, it could be a disaster.

That's about all I know about handles.  I recommend the book _Macintosh
Programming Primer_ by Dave Mark and Cartright Reed.  It uses THINK
Pascal.  They also have two books with similar titles using C.  I hope
this helps.

Dave Shortt
[e-mail]



+++++++++++++++++++++++++++

>From [e-mail] (Matthew Xavier Mora)
Date: Wed, 15 Mar 1995 10:18:23 -0800
Organization: SRI International

In article <[e-mail]>,
[e-mail] (Rhys EleScryer) wrote:

>I am currently trying for the first time in any of my programs to use a handle.
>I just don't quite have the hang of it. Here's what I've done:
>After putting some text into a string variable (theString):
>
>theHandle:= NewHandle(SizeOf(theString));
>theHandle^:= @theString;

Yeow!

Try :

oe:=PtrToHand(Ptr(@theString),theHandle,length(theString)+1);

or

theHandle := NewHandle(0);
oe := PtrAndHand(Ptr(@theString),theHandle,length(theString)+1);

if you don't want the length byte in the handle then do a
Ptr(ord(@theString)+1) and don't add one to the length.



Xavier

--
__________________________________________________________________
Matthew Xavier Mora  (cybernaut)            The keeper of the UMPG
SRI International                              [e-mail]

"Indeed, it would not be an exaggeration to describe the history
of the computer industry for the past decade as a massive attempt
to keep up with Apple." Byte 12/94

+++++++++++++++++++++++++++

>From [e-mail] (Peter N Lewis)
Date: Thu, 16 Mar 1995 12:15:47 +0800
Organization: Curtin University

In article <[e-mail]>,
[e-mail] (Rhys EleScryer) wrote:

>I am currently trying for the first time in any of my programs to use a handle.
>I just don't quite have the hang of it. Here's what I've done:
>After putting some text into a string variable (theString):
>
>theHandle:= NewHandle(SizeOf(theString));
>theHandle^:= @theString;
>
>This is just plain wrong. I mean it compiles and runs fine, but I end up
>with garbage in my variable. Could some kind soul point me in the right
>direction when it comes to these nasty buggers?

Well, here are some dos and donts.

First off, a Handle is more than just a pointer to a pointer.  The Memory
manager knows about handles and does magical things with them like moving
them around your heap if you let them (to avoid fragmentation), resizing
them and so on.  You should never make "fake" handles, which are simply
pointers to pointers.  Also, you should never manipulate h^ (like you're
doing above).

You could do what you want with:

h:=NewHandle(SizeOf(Str255));
StringHandle(h)^^:=s;

But probably better is:

h:=NewHandle(length(s)+1);
BlockMoveData(@s,h^,length(s)+1);

The difference is that instead of a 256 byte handle with a small string at
the end of it, you have a small handle that just fits the string (the +1
is to add room for the length byte).

Of course, the best way to do this is:

SetString(StringHandle(h),s);

Which lets the OS figure it out for you, but that's not very informative.

For the truely daring, you could use munger on a given handle:

junk_long:=Munger(h,0,nil,GetHandleSize(h),@s,length(s)+1);

One further thing to always remember about handles is the difference
between memory handles and resource handles.  It is vitally improtant you
keep track of which handles are which.  When you get a resource (using
GetResource for example), you are returned a resource handle.  This has
all the special properties of a memory handle, but is also known by the
resource manager to be a resource handle.  You must NOT DisposeHandle it,
because then the resource manager would still remember it.  You need to
get rid of it using ReleseResource.  Also, if you close the resource file
the resource handle comes from, the resource will be automatically
released by the resource manager (making the handle invalid, so you can't
use it after that).  You can turn a resource handle into a regular memoyr
handle using DetachResource.  The reverse can be done using AddResource,
which takes a memory handle and adds it to a resource file, turning the
memory handle into a resource handle at the same time.

It's all very complicated, but you should get the hang of it after a
while.  Two useful inits DoubleTrouble and DisposeResource can be very
helpful at tracking down problems, they drop you into macsbug when you
DisposeHandle a resource handle, or DisposeHandle a handle you've already
disposed.

Enjoy,
   Peter.
--
The best movie I've seen recently is "Heavenly Creatures" from New Zealand

---------------------------

>From [e-mail] (Michael Tank Stack)
Subject: OSAExecute and AS subroutines
Date: Fri, 03 Mar 1995 08:52:36 -0800
Organization: StarNine Technologies, Inc.

I am having a little difficulty w/ OSAExecute and Applescripts and was
wondering if anyone else had come across the same behavior?

If I write an applescript with sub-routines calls and compile it in
script-editor, in my program I can use OSALoad and OSAExecute to run the
script w/o problem.

If I pass the same script as text to OSACompile and subsequently to
OSAExecute, the script fails  at the call to the sub-routine w/ a "<<My
Script Name>> doesn't understand the <My Sub-Routine Name> message." and a
-1708 error. The same code will not fail if the script is written straight
w/o sub-routines.

I've tried a few things such as the qualifier "of me" etc. and wandering
through doc sheds but to little effect.  Any help or pointers would be
much appreciated.

Thanks,

St.Ack

+++++++++++++++++++++++++++

>From [e-mail] (Jon Pugh)
Date: Fri, 10 Mar 1995 01:05:02 GMT
Organization: Will hack for food

Michael Tank Stack ([e-mail]) wrote:

> If I write an applescript with sub-routines calls and compile it in
> script-editor, in my program I can use OSALoad and OSAExecute to run the
> script w/o problem.

> If I pass the same script as text to OSACompile and subsequently to
> OSAExecute, the script fails  at the call to the sub-routine w/ a "<<My
> Script Name>> doesn't understand the <My Sub-Routine Name> message." and a
> -1708 error. The same code will not fail if the script is written straight
> w/o sub-routines.

I'll bet you aren't using the OSAModeCompileIntoContext flag on OSACompile.
You need to use this when compiling a script so that things get set up
properly.

Jon


+++++++++++++++++++++++++++

>From Patrick C. Beard <[e-mail]>
Date: 11 Mar 1995 02:23:52 GMT
Organization: Computing Research Group

In article <[e-mail]> Michael Tank Stack, [e-mail]
writes:
>I am having a little difficulty w/ OSAExecute and Applescripts and was
>wondering if anyone else had come across the same behavior?
>
>If I write an applescript with sub-routines calls and compile it in
>script-editor, in my program I can use OSALoad and OSAExecute to run the
>script w/o problem.
>
>If I pass the same script as text to OSACompile and subsequently to
>OSAExecute, the script fails  at the call to the sub-routine w/ a "<<My
>Script Name>> doesn't understand the <My Sub-Routine Name> message." and a
>-1708 error. The same code will not fail if the script is written straight
>w/o sub-routines.

Here's a little class I whipped up a while back to make it easier to work
with OSA scripts. Hopefully this will help others out too. Here's how you
could use this class:

#include "OSAScript.h"

static char* initScript = "\r\
on fact(n)\r\
        if n <= 1 then\r\
                return 1\r\
        else\r\
                return n * fact(n - 1)\r\
        end if\r\
end fact\r";

void main()
{
        printf("testing OSAScript.\n");
        OSAScript script(initScript);
        script.Compile("fact(10)");
        printf("fact(100) = %s\n", script.Execute());
}

// author:          Patrick C. Beard
// organization:    Computing Research Group
// e-mail:          [e-mail]

/*
        OSAScript.h

        A class for managing OSA Scripts.

        by Patrick C. Beard.
 */

#ifndef __OSA_SCRIPT__
#define __OSA_SCRIPT__

#include <OSA.h>

class OSAScript {
public:
        OSAScript(char* initScript = nil);
        ~OSAScript();

        void Compile(const char* script);
        const char* Execute(void);
        OSErr Result() { return itsResult; }

private:
        OSErr itsResult;
        OSAID itsScriptContext;
        AEDesc itsScriptResult;
};

#endif

/*
        OSAScript.cp

        A class for managing OSA Scripts.

        by Patrick C. Beard.
 */

#include "OSAScript.h"
#include <string.h>

static ComponentInstance theComponent= nil;
static short theScriptCount = 0;

OSAScript::OSAScript(char* initScript)
{
        if (!theComponent)
                theComponent = OpenDefaultComponent(kOSAComponentType, kOSAGenericScriptingComponentSubtype);
        ++theScriptCount;

        itsResult = noErr;
        itsScriptContext = kOSANullScript;
        itsScriptResult.descriptorType = typeNull;
        itsScriptResult.dataHandle = nil;

        // precompile a context to hold variable bindings, etc.
        if (initScript) Compile(initScript);
}

OSAScript::~OSAScript()
{
        if (itsScriptResult.descriptorType != typeNull)
                AEDisposeDesc(&itsScriptResult);

        if (itsScriptContext != kOSANullScript) {
                OSADispose(theComponent, itsScriptContext);
                itsScriptContext = kOSANullScript;
        }

        // if last script in existence, tear down the component.
        if (--theScriptCount == 0 && theComponent != nil) {
                CloseComponent(theComponent);
                theComponent = nil;
        }
}

void OSAScript::Compile(const char* script)
{
        AEDesc scriptDesc;
        scriptDesc.descriptorType = typeChar;
        PtrToHand(script, &scriptDesc.dataHandle, strlen(script));
        itsResult = OSACompile(theComponent, &scriptDesc, kOSAModeAugmentContext, &itsScriptContext);
        AEDisposeDesc(&scriptDesc);
}

static const char* AEDescToCString(AEDesc& desc)
{
        if (desc.descriptorType != typeChar)
                return nil;

        Handle textH = desc.dataHandle;
        long textSize = GetHandleSize(textH);
        SetHandleSize(textH, 1 + textSize);
        HLock(textH);

        char* str = *textH;
        str[textSize] = '\0';

        return str;
}

const char* OSAScript::Execute()
{
        OSAID scriptValue;

        // dispose of any previous result text.
        if (itsScriptResult.descriptorType != typeNull)
                AEDisposeDesc(&itsScriptResult);

        // execute the result in its own context. this augments the environment.
        itsResult = OSAExecute(theComponent, itsScriptContext, itsScriptContext,
                                                kOSAModeAlwaysInteract, &scriptValue);

        // check for errors.
        if (itsResult != noErr) {
                itsResult = OSAScriptError(theComponent, kOSAErrorMessage, typeChar, &itsScriptResult);
        } else {
#if 1
                itsResult = OSADisplay(theComponent, scriptValue, typeChar,
                                                        kOSAModeNull, &itsScriptResult);
#else
                itsResult = OSADisplay(theComponent, scriptValue, typeChar,
                                                        kOSAModeDisplayForHumans, &itsScriptResult);
#endif
                OSADispose(theComponent, scriptValue);
        }

        return AEDescToCString(itsScriptResult);
}

---------------------------

>From [e-mail] (ALTURA)
Subject: [Ann] FREE QuickView Development Kit
Date: 17 Mar 1995 13:02:24 -0500
Organization: America Online, Inc. (1-800-827-6364)

FOR IMMEDIATE RELEASE CONTACT:
Lee Lorenzen, President
Altura Software, Inc.
408.655.8005

Altura Software Announces QuickView Developer Edition

PACIFIC GROVE, California -- March 16, 1995 -- Altura Software, Inc.
announced today that it will be making available its popular QuickView(tm)
Development Kit for the personal use of developers free of charge.  The
Kit will appear on the next major release of the Metrowerks CodeWarrior
CD-ROM and the June 1995 Apple(R) Developer CD Reference Library Edition.

MAJOR BENEFITS FOR DEVELOPERS
Developers will be able to create QuickView databases that integrate with
Apple's Macintosh(R) Programmer's Toolbox Assistant.  Key features of
these databases are:

* Hypertext links
* Graphics, sound and QuickTime Movies
* Full Text Search Indexing
* Popup definition windows
* Sticky notes for annotation
* Integration with major third-party development environments such as
Metrowerks CodeWarrior

Source files created for QuickView are by definition cross-platform
because QuickView uses the same source file format as Microsoft's popular
Multimedia Viewer 2.0 on Windows.

"Metrowerks is working closely with Altura to standardize all online
CodeWarrior help on QuickView," said Greg Galanos, President and CEO of
Metrowerks Inc.  "QuickView is a godsend for online help and interactive
referencing and we're happy to announce that you'll see QuickView
databases
for CodeWarrior in the CW6 release. We're also happy to announce that
Altura will be distributing their QuickView Developer's Kit on CW6."


QUICKVIEW DEVELOPER EDITION
Altura has created the QuickView Developer Edition which consists of the
standard QuickView Development Kit along with beta versions of its newly
created authoring tools, authoring documentation, and many sample files.

Users of the QuickView Developer Edition will have the right to compile
and view databases for their personal use free of charge.  However, they
won't be able to redistribute these databases.  Distribution licenses are
available for an annual flat rate per title (commercial and non-commercial
pricing is available).  Contact Altura Software for pricing information.
Databases created with the Developer Edition have a small "demonstration
notice" at the beginning of each database topic.

"The QuickView Developer Edition is a boon to Mac developers because it
allows them to create documentation for their own code libraries that
integrate with Apple's Macintosh Programmer's Toolbox Assistant," remarked
Jordan Zimmerman (one of QuickView's creators).  "Not only is it free, but
it also provides the same rich feature set that has made Macintosh
Programmer's Toolbox Assistant so powerful."


ABOUT QUICKVIEW
QuickView is a Microsoft Multimedia Viewer-compatible multimedia and
online reference development tool.  Apple Computer recently used QuickView
to develop its Macintosh Programmer's Toolbox Assistant.  QuickView
features:

* Multimedia support - QuickTime and Sound
* Graphics support - PICT and PICTs with hotspots
* Full Text Indexing (query using AND, OR, NOT, NEAR, THRU)
* Context-sensitivity and Hypertext links
* Popup Definitions
* Sticky Notes for annotations
* Cross-platform (Microsoft Multimedia Viewer 2.0 compatible)
* Rich macro language
* Native Mac look-and-feel

QuickView is fast becoming a standard for online reference and
cross-platform multimedia on the Mac.  Apple, Microsoft, Claris,
Metrowerks, and many others are using QuickView.


ABOUT ALTURA SOFTWARE
Altura Software, Inc. is a leading developer of porting technology
solutions for the Macintosh and Windows platforms.  The company's
Mac2Win(tm) technology gives software developers unparalleled solutions
for quickly moving their Macintosh applications to Windows.  Altura
Software also offers QuickHelp(tm), the WinHelp compatible, context
sensitive help system for Macintosh; and QuickView, the Microsoft
Multimedia Viewer-compatible multimedia and online reference development
tool.  Altura Software, Inc. was founded in 1990 and is based in Pacific
Grove, California.

For more information on Altura Software and its products, please contact
Lee Lorenzen at 408-655-8005.

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #

Apple Computer, Inc., a recognized pioneer and innovator in the
information
industry, creates powerful solutions based on easy-to-use personal
computers,
servers, peripherals, software, online services, and personal digital
assistants.  Headquartered in Cupertino, California, Apple (NASDAQ: AAPL)
develops, manufactures, licenses, and markets products, technologies, and
services for the business, education, consumer, scientific and engineering
and
government markets in over 140 countries.

Founded in 1985, Metrowerks Inc. develops and sells programming tools for
the Macintosh.  Metrowerks currently has over 9,000 registered users in
over 40 countries. Metrowerks began publically trading on the Vancouver
Stock Exchange on March 11, 1994 under the symbol MWK.

Metrowerks and the Metrowerks logo are registered trademarks of
Metrowerks, Inc. CodeWarrior is a trademark of Metrowerks, Inc.  Apple,
Macintosh, and Mac, are registered trademarks of Apple Computer, Inc.  All
other trademarks and registered trademarks are the property of their
respective owners.


---------------------------

>From [e-mail] (J.A. Safranek)
Subject: [HELP] How would I add to the Help Menu?
Date: 8 Mar 95 03:48:10 GMT
Organization: Iowa State University, Ames, Iowa

I am making a utility with CW5 and I want to add a help feature to the
help menu. The problem I am having is I don't know how to add to the
Help menu. I have the SpInside Mac HyperCard Stack and it has nothing on
this. I tried adding a 'hmnu' menu with ResEdit and had it add the menu.
But it just put a hmnu on the menu bar. Can someone please tell me how I
go about doing this. Thanks.

    -John A. Safranek

- ----------------------------------------------------------------------------
         _   "And that, my friend, is a specialty bread."
        [ ]   - Tom Servo
       (   )       -----------------------------------------------------------
        |>|        Email:         [e-mail]
     __/===\__     WWW Home Page: http://www.public.iastate.edu/~tomservo/
    //| o=o |\\    -----------------------------------------------------------
  <]  | o=o |  [>  On Laplace Transforms:
      \=====/        "They aren't as good as a cold beer. But by God, they
     / / | \ \        sure do come close!" - C. Comstock
    <_________>    -----------------------------------------------------------
                                Bring back the Tenth Amendment!
- ----------------------------------------------------------------------------


+++++++++++++++++++++++++++

>From [e-mail] (Richard Taylor)
Date: Thu, 9 Mar 1995 21:11:26 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

J.A. Safranek ([e-mail]) wrote:
: I am making a utility with CW5 and I want to add a help feature to the
: help menu. The problem I am having is I don't know how to add to the
: Help menu. I have the SpInside Mac HyperCard Stack and it has nothing on
: this. I tried adding a 'hmnu' menu with ResEdit and had it add the menu.
: But it just put a hmnu on the menu bar. Can someone please tell me how I
: go about doing this. Thanks.

Here's how I do it:

if sysConfig.hasHelpMgr then begin {use gestalt to be sure you have helpMgr}
   err := HMGetHelpMenuHandle(LocalHelpMenu); {get =your= local handle}
   if (err = noerr) and (LocalHelpMenu <> nil) then
    AppendMenu(localHelpMenu, 'Your Help Item Goes Here');

This adds your item to the Help menu.

Then when you're processing menu commands include this:

Case MenuID of
{your other menus...}

kHMHelpMenuID:
  {do your help menu command}


You can add more than one and you can get a menu item count but if you
're just adding one item the above will work.

--
richard taylor:     [e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Chris Watson)
Date: Sat, 11 Mar 1995 17:36:15 -0500
Organization: Communications Accessibles Montreal, Quebec Canada

In article <[e-mail]>,
[e-mail] (J.A. Safranek) wrote:

> I am making a utility with CW5 and I want to add a help feature to the
> help menu. The problem I am having is I don't know how to add to the
> Help menu. I have the SpInside Mac HyperCard Stack and it has nothing on
> this. I tried adding a 'hmnu' menu with ResEdit and had it add the menu.
> But it just put a hmnu on the menu bar. Can someone please tell me how I
> go about doing this. Thanks.

There is a call that returns a handle to the Guide (or Help) menu.  It is
something like HMGetHelpMenuHandle ()... something like that, check
Balloons.h

hope it helps...


.:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::.
|    Chris Watson                                                   |
|    [e-mail]            Hooked on foniks werkes four me!    |
|    Montreal, Canada                                               |
i:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::i

---------------------------

End of C.S.M.P. Digest
**********************



Attachment converted: Spiff:ShowInit-7.sit (SITD/SIT!) (0001D423)